Data stream displayName should be noun-based per repo guidelines; Search reads as a verb/action. Consider renaming to something like "Search results"/"Results" (whatever best matches the returned shape).

author.type is set to "labs", but repository guidance and existing plugins use "community" for community-authored plugins. Please update author.type to community and set author.name to a GitHub username (e.g. @username) or an organisation name.

This plugin adds a top-level README.md, but other plugins typically provide end-user help in docs/README.md (and metadata links point there). Consider moving this content into docs/README.md; also avoid starting with an "Overview" heading per repo doc guidance for embedded help.

data.aggregations in OpenSearch responses is an object, not an array, so data.aggregations.length > 0 will always be false and aggregation results will never be returned. Use Object.keys(data.aggregations).length (or similar) to detect/handle aggregations before selecting the last aggregation.

Docs are provided as docs/setup.md, but the repo convention (and in-product rendering) is docs/README.md. Also, the top heading here is # Configuration, whereas other plugins start with task-focused headings like # Before you start (e.g. plugins/UniFi/v1/docs/README.md:1). Please rename to docs/README.md and align the heading structure so setup guidance is what users see in SquaredUp.

This file is named README.md under the plugin version folder, but other plugins keep end-user setup docs under docs/README.md and don’t include a top-level README.md. Additionally, the PR description/checklist says the README includes configuration guidance, but this file is only an overview. Consider moving/merging this content into docs/README.md so users can find both overview + configuration in one place.

The documentation link points to docs/setup.md, but other plugins consistently link category: documentation to docs/README.md (e.g. plugins/UniFi/v1/metadata.json:31-35). SquaredUp also only renders docs/README.md in-product, so this should be renamed/moved to docs/README.md and the URL updated accordingly.

Consider adding an explicit CODEOWNERS entry for this new plugin so future changes request review from the plugin author (see .github/CODEOWNERS, which lists each existing plugin).

According to the custom guidelines, ui.json placeholders should use example values where a value follows a fixed pattern. For a URL field, consider providing a more specific example placeholder that shows the expected format, such as "https://your-opensearch-host:9200" instead of the generic instruction "Enter the OpenSearch URL".

The script assumes that when there are no aggregations, data.hits.hits will always exist and have a _source property. However, if the OpenSearch query fails or returns an unexpected structure, this could cause a runtime error. Consider adding defensive checks to handle cases where data.hits or data.hits.hits might be undefined, or where individual hits might not have a _source property.

According to the custom guidelines, API tokens or OAuth are preferred over username/password authentication where possible. OpenSearch supports API key authentication as an alternative to basic authentication. Consider adding support for API key authentication to provide a more secure authentication option. If basic authentication is the only viable option for your use case, this is acceptable, but API keys would be preferred.

According to the custom guidelines, for community-authored plugins, the author type should be set to "community" and the name should typically be a GitHub username prefixed with @ (e.g., "@username") or an organization name. The PR description indicates this is a community contribution, but the metadata shows "SquaredUp Labs" with type "labs". Please update to reflect the actual community author, for example:

"author": {
    "name": "@yourusername",
    "type": "community"
}

According to the custom guidelines, dataStreams should have a description field that is typically one sentence only with no full stop at the end. Consider adding a description to this data stream, such as "Query OpenSearch indices using DSL syntax" to help users understand what this data stream does.

According to the custom guidelines, the description should focus on what users can build or monitor, avoiding API or implementation language. The current description "Query OpenSearch databases using DSL" is quite technical. Consider rephrasing to something more user-focused, such as "Monitor and analyze data from OpenSearch databases." to better describe what users can achieve with this plugin.

According to the custom guidelines, help text should "Start with a verb where possible". The current help text "The Query DSL JSON. See [OpenSearch API docs]..." starts with "The" rather than a verb. Consider rephrasing to start with a verb, such as "Specify the Query DSL JSON. See [OpenSearch API docs]..." or "Enter the Query DSL JSON. See [OpenSearch API docs]..." to follow the guideline more closely.

According to the custom guidelines, help text should "Start with a verb where possible". The current help text describes the authentication modes but doesn't start with a verb. Consider rephrasing to start with a verb, such as "Choose Basic to authenticate with username and password, or Anonymous access when no authentication is required." However, given the multi-option format with markdown bold formatting, the current structure may be acceptable for clarity.

According to the custom guidelines, for ui.json fields, labels should follow the pattern "First word uppercase, then lowercase" (e.g., "Table name" or "API key"). The current label "Instance URL" has both words capitalized. Consider changing it to "Instance url" to align with the guidelines, though "URL" is commonly capitalized as an acronym. If keeping "URL" capitalized, this should be consistent with other similar fields in the codebase.